For many years, reporting and analysis applications based on a relational data model have had the capability to produce somewhat ad-hoc ‘attribute’ based totals by summarizing data based on the values of ‘attributes’. In this scenario, ‘attributes’ are one-dimensional facts about a particular member or position, such as the supplier of an item, the region a location belongs to, and similar facts, that can be joined with the facts being reported and ‘analyzed’ by various forms of sub-totaling. These ‘attributes’ are often positioned as being ‘dimensions’ even though such ‘dimensions’ do not represent the same thing as a dimension in a multi-dimensional model.
OLAP (Online Analytical Processing) and multi-dimensional planning applications (MDP) have traditionally taken a different approach. MDP applications, that are used for Merchandise Planning, for example, are those applications that are OLAP-type applications but with powerful facilities for a user to change data values, and have the application automatically recalculate all other related values. In these types of applications, members are related together into dimensions. In the example for merchandise planning systems, a member is an individual product, or individual locations represented in a dimension. A dimension here represents all different types of related members, for example all types of locations. In a dimension, similar types of members are grouped into levels, where levels may represent entities such as stores, regions, areas, and other groupings of entities for the example merchandise planning systems. Levels are related together through parent-child relationships that are used to build hierarchies. Thus, for example, stores may be the children of districts, which may be the children of regions, which may be the children of areas. This hierarchy can be represented schematically by the diagram 101 shown in FIG. 1a. 
In FIG. 1a, the hierarchy 101 starts with a value for a “store 223” 111. The total sales for this store 111 is included within a total for the west region 112, and then the US area 113, and finally for the total for the entire company 114. Of course, the totals for the various levels in the hierarchy include values for other stores, areas, and regions within the various totals.
In OLAP and MDP applications, the hierarchies define the consolidation, or aggregation. paths for producing roll-ups, which occur automatically once the hierarchy is defined. These hierarchies are typically predefined through some administrative process or interface, and may be referred to as formal hierarchies to distinguish them from attribute hierarchies. OLAP and MDP applications typically support multiple hierarchies in a single dimension. These multiple hierarchies are usually referred to as alternate hierarchies. Thus if the example location hierarchy, shown in FIG. 1a, represents an operational location hierarchy in a retail organization, the same stores may also be analyzed by their fascia in an alternate hierarchy 102 is illustrated within FIG. 1b. In this alternate hierarchy 102, the store value 121 as shown at the bottom of the hierarchy 102. An intermediate value 122 is shown for the fascia and the total for the company 123 is at the top of the hierarchy 102. Any number of such hierarchies are possible.
It could be argued that the fascia 122 of a store 121 is an attribute, and for some OLAP and MDP applications such attribute hierarchies may be built dynamically when required by the user from the values of attributes. In those applications, the decision as to whether any particular relationship should be modeled as a formal hierarchy or attribute hierarchy is one of ease of use, ease of definition, and performance tuning for the application.
However, this approach to building dynamic attribute hierarchies by OLAP and MDP applications does not provide for any type of cross attribute analysis. If the attributes have fairly static values, and there is a very small number of such values, formal alternate hierarchies may be built that allow some limited form of cross attribute analysis. For example, if two attributes of an item are a price point (PP) and a country of origin (COO), the alternate hierarchies could be built as shown in FIG. 2.
These alternate hierarchies 201–202 provide for members that represent individual price points (such as high, medium, and low) and countries of origin. It also allows limited cross attribute analysis as there are members that represent combinations of these attributes, such as USA/high pp, USA/medium pp, Canada/medium pp, and any other combination of attributes. However, this formal alternate hierarchies approach cannot be used with more dynamic attributes and becomes an administrative and end-user nightmare when there are more than a small number of attributes, as a very large number of formal alternate hierarchies would need to be maintained and used. The present invention as described herein as a system and method for providing cross attribute analysis and manipulation in Online Analytical Processing (OLAP) and multi-dimensional planning applications by dimension splitting provides for a solution to this problem.